Thanks @ScottPJones. A couple of comments:

• You shouldn't include your name "[Scott Paul Jones]" in the commit message; git already attaches your github username to the commit.
• For a commit that fixes an issue (here utf16 and related functions don't handle characters >= 0x100000 correctly #10919), you should include "(fixes utf16 and related functions don't handle characters >= 0x100000 correctly #10919)" or similar in the commit message. That way, when the commit is merged, issue utf16 and related functions don't handle characters >= 0x100000 correctly #10919 will automatically be closed on Github. You'll also notice that Github automatically inserts cross-links between this pull request and utf16 and related functions don't handle characters >= 0x100000 correctly #10919.
• Shouldn't there be a @test_throws ArgumentError utf16(UInt16[...some invalid data...]) test?

Note that you can amend the commit by making the changes, doing git commit --amend, and then doing git push -f ..... to overwrite your old commit.

(I noticed that you pushed the change to your master branch. This is fine, but in future pull requests you probably work on a different branch, e.g. via git checkout -b utf16_fix to create a separate branch. This will make life easier for you in multiple ways.)

git already attaches your github username to the commit

And your real name in the author field as long as you've configured git config --global user.name.

Hmmm... I’d like to also change it so that it displays the character value when it gets the ArgumentError... I have checked that it doesn’t create a GC frame or change in-line ability, as Stefan was concerned about, but my problem is that doing $c interpolates the number in decimal, and I want it out as 0x and hex digits... (I know this is a stupid newbie question!)

Ah, never mind, found it! 0x$(hex(c))

I have now updated the tests to add all of the suggestions. Thanks!

Now, I'd like to look at improving the performance of some of these functions in utf8, utf16, and utf32...
The code does Buff = Uint16[], and then a push! for every character... I did a simple test, and changing things to Buff = Array{UInt16,1}(len) and then setting each element was 5 times faster, with 1/2 the memory allocated, 1/2 the GC time and 1/2 the # of pauses...
(just a for loop of a million times, doing buff = UInt16[] ; for j=1:20 ; push!(buff,j) ; end, or buff = Array{UInt16,1}(20) ; for j=1:20 ; buff[j] = j ; end) )

I now know I messed up by pushing from my master... can you please help a newbie out, and tell me
what I need to do to get my GitHub repository (master) sync'ed back up to be the same as JuliaLang/julia...
I assume then if I do the "git checkout -b utf16_fix", I'll be fine for the next round of changes, right?

Thanks so much everybody!

This should be a reasonably bulletproof recipe. I assume here that you have two remotes; "julialang" is the remote that points at the JuliaLang/julia repository on GitHub, and "mine" points at ScottPJones/julia on GitHub. Substitute as needed. You can check your remotes with git remote -a.

git checkout master
git branch old-master #this is your backup branch pointer if this goes wrong
git fetch julialang master #grab the latest commits
git reset --hard julialang/master #this will modify the working copy and branch pointer to resync to master; you shouldn't normally need to do this
git checkout -b topic/make-utf16-fast #new working branch
git push mine HEAD  #push topic/make-utf16-fast to your GitHub repository

Oh, and don't worry about your master branch on GitHub being out of sync...in fact, you don't even need it:

git push mine --delete master #delete remote master branch
git push mine :master #same thing, oldskool syntax ("push nothing to master")

@pao I did what you said, but after that, when I tried to rebuild, I got a strange error:

 cd ../.. && /bin/sh /Volumes/Dynize/julia/deps/fftw-3.3.4-double/missing automake-1.14 --gnu dft/simd/Makefile
/Volumes/Dynize/julia/deps/fftw-3.3.4-double/missing: line 81: automake-1.14: command not found
WARNING: 'automake-1.14' is missing on your system.
         You should only need it if you modified 'Makefile.am' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'automake' program is part of the GNU Automake package:
         <http://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <http://www.gnu.org/software/autoconf>
         <http://www.gnu.org/software/m4/>
         <http://www.perl.org/>
make[5]: *** [Makefile.in] Error 127
make[4]: *** [install-recursive] Error 1
make[3]: *** [install-recursive] Error 1
make[2]: *** [/Volumes/Dynize/julia/usr/lib/libfftw3.dylib] Error 2
make[1]: *** [install-fftw] Error 2
make: *** [julia-deps] Error 2

I actually have automake version 1.15 installed on my Mac... did something change in the last two days?
Julia built fine two days ago, from the fork that I made for fix #10919...

Thanks, Scott

some timestamp issue might be confusing autotools - try make -C deps distclean-fftw which will clear out the existing fftw build and re-do it from scratch

What @tkelman said is a good general rule of thumb for weird-looking dependency build problems.

Thanks @tkelman & @pao, I ended up "fixing" the problem by completely removing my local git repository and rebuilding from scratch, your advice will help save me some hours the next time that happens!

There's a final tier of cleanliness if make distclean doesn't work. You can remove all files not checked into the repository with git clean, which at least avoids needing to check out the repository again. I'll ask that you look up the arguments yourself so that you understand them, because this particular git function can cause dataloss.

backported in 8eafd07